Review

Return to TOC

Review

• OOA
  • requirements analysis
• OOD
  • modeling conceptual classes, understanding software objects
• Representational Gap
  • difference between domain logic and implementation
  • as low as possible
• Iterative Development
  • Waterfall model
    • do all steps once for the whole project
    • all requirements are defined once and frozen
    • then design activities are done and frozen
  • prefer to iteratively conduct requirements analysis, understanding, testing, etc. multiple times
  • the shorter the iteration, the better
• Agile
  • individuals + interactions > processes + tools
  • working software over comprehensive documentation
  • customer collaboration > contract negotiation
  • responding to change > following a plan
• XP
  • extremely short iterations (like one week)
  • pair programming
    • driver and navigator, alternating
  • root cause analysis
    • ask Why? 5 times
  • ubiquitous language
    • same language to customer, reusing names
  • done done
    • done when ready for deployment
  • stories
    • customer-centric (mean something to the customer)
    • clear completion criteria
  • customer tests
    • customer knows the problem domain; convert success steps into tests
• Scrum
  • artifacts
    • product backlog
      • list of tasks, features, etc. needed to be implemented over the course of production
    • sprint backlong
      • subset of product backlong for specific sprint
  • ceremonies
    • sprint planning
      • moving from product backlong to sprint backlog at the start of a sprint
    • daily scrum
      • daily meeting to discuss
    • sprint review
      • is the software ready for production?
    • sprint retrospective
      • what is something to focus on in the next sprint?
      • what did we do well?
  • reports
    • velocity reports
      • average rate of closing story points
    • burndown chart
      • assign points to stories
      • compare work done (points) to work intended

Requirements Engineering (OOA)

• functional requirements: functions of the system
• non-functional requirements: "-ility", hard to measure (not specific)
• verification
  • verify software against test plan
• validation
  • validate if it matches the customer needs
• requirements must be:
  • identifiable
    • easy to refer to with a simple ID
  • prioritized
    • limited resources
    • different from story points because this is customer priority while story points show difficulty/time commitment
  • testable
  • (eventually) estimated
    • assign story points
• Test Driven Development
  • failure
    • incorrect behavior
  • fault
    • necessary condition for failure; bug in code
  • error
    • cause of fault, usually human error
  • dynamic technique
    • attempting to make it fail; must execute the code
  • optimistic approximation
    • cannot test every input possibility
    • test on small subset that is hopefully representative of all behaviors
  • testing granuity levels
    • unit testing
      • testing individual components
    • integration testing
      • testing to make sure it components work together properly
    • system testing
      • test the whole system, non-functional requirements testing
    • acceptance testing
      • tests for the client to accept the software
      • requires clear outline of the requirements for the software to be accepted
    • regression testing
      • testing to ensure new components do not break old components
  • testing "phases"
    • developers' testing
    • alpha testing
      • testing within the company
      • internal users
    • beta testing
  • TDD cycle
    • write tests first, then write code
• Use Cases
  • must have at least one scenario: happy path or main success scenario
  • Boss test
    • would your boss be happy
  • EBP test
    • Is it accomplishable/doable? Is it not too hard?
  • Size tests
    • Is it too simple? Is it not too easy?
      • "scanning a product" use case will be too simple
  • Use Case Diagram
    • primary actors left, supporting actors right, use cases in the middle in a box, connecting actors with use cases
  • Domain Model
    • has multiplicity and bidirectionality arrows only when reader is intended to read relationships in an unusual manner
  • SSD
    • show interactions between the user and the black-box system